Amazon Athena キャパシティ予約ができるProvisioned Capacityについて徹底解説！

データアナリティクス事業本部のコンサルティングチームの石川です。Amazon Athenaは、既存のスキャンしたデータのサイズに応じた課金に加え、キャパシティ予約したDPU数と時間に応じた課金によるサービス開始しました。この本日は、コンピューティングのキャパシティ予約ができるProvisioned Capacityを紹介します。

Provisioned Capacityとは

Provisioned Capacityは、クエリの実行専用にDPU(Data Computing Units)と呼ばれるコンピューティングとその数を事前に確保します。Provisioned Capacityは、クエリの同時実行性やコストなどのワークロードのパフォーマンス特性を制御できます。指定したDPU数と時間に応じて料金が発生します。

Provisioned Capacityは、新たに導入されたワークロード管理機能を用いてワークグループに対して割り当てます。よって、Provisioned Capacityを割り当てていないワークグループのクエリは従来の課金が適用されます。

特長

• 重要なインタラクティブワークロードの優先順位付け、制御、スケーリングに役立つ
  • ミッションクリティカルなクエリに専用のコンピューティングを割り当てに有用
  • クエリを優先制御できる
• クエリの同時実行性やコストなどのワークロードのパフォーマンス特性を制御できる
  • 予約したキャパシティに応じてクエリを同時実行性を確保できる
  • 料金が予測可能になり、毎月の予算内に収まるようにユーザークエリを制限が容易になる
• Provisioned Capacityの大きさに応じてスループットが予測しやすくなる
  • 大きなProvisioned Capacityを確保、割当することでレスポンスを改善できる

キャパシティ予約の設定

Provisioned Capacityは、キャパシティ予約を作成した後、キャパシティ予約にワークグループを割り当てるだけです。

キャパシティ予約の作成

Capacity reservation nameとDPUに最小値の24を指定します。

下記のメッセージのある通り、現在のキャパシティ予約のAnalystic Engineは、グレーアウトされており、Athena engine version 3でのみサポートされているようです。

東京リージョンのアカウントに24DPUをリクエストします。予約完了後、予約のStatusがActiveになった時点から予約をキャンセルし、実行中のクエリーが終了するまでの間、DPU1時間ごとに請求されます。

今回は、最小でも82.56USDの料金が発生してしまうので、確認はここまでとさせていただきます。m(＿ ＿)m

クエリにキャパシティを割り当てる

キャパシティ予約のStatusがActiveになったら、適用したいWorkgroupを設定します。割り当てられたワークグループに属するクエリは、プロビジョニングした容量で実行されます。

キャパシティ予約は、複数作成してそれぞれWorkgroupを割り当てることも可能です。

最小構成とコスト

Provisioned Capacityの単位は、DPU(Data Computing Units)です。Provisioned Capacityが最も適しているユースケースは、Athenaに毎月100ドル以上利用する場合です。

• 1つのDPUは、4つのvCPUと16GB RAMに相当

• プロビジョニングできる最小キャパシティは、24DPU、8時間

• アカウントとリージョンごとに、合計1,000個のDPUを持つキャパシティ予約を最大100個まで作成可能

  • 1000個以上のDPUが必要な場合は、[email protected] までご連絡
• 東京リージョンの場合は、0.43USD/Hour
  • 最低8時間の料金：82.56USD = 24(DPU) × 8(時間) × 0.43(USD)

キャパシティ予約の決定

クエリに必要な DPU の数を決定するには、 実行するクエリの種類や同時実行クエリ数に決めます。

実行するクエリの種類

• DDLクエリ：4つのDPUを消費する
• DMLクエリ：通常4から124のDPUを消費する

同時実行クエリ数

同時実行クエリ数と必要なDPU数の一般的な目安は以下のとおりです。

同時実行クエリ数	必要な DPU数
10	40
20	96
30以上	240

割り当てられた容量が不十分であることを示す兆候

キャパシティ不足のエラーメッセージでクエリーが失敗する場合、キャパシティ予約のDPU数がクエリーのワークロードに対して少なすぎる可能性があります。例えば、24DPUの予約で、24DPU以上を必要とするクエリーを実行した場合、クエリーは失敗します。

割り当てられたキャパシティ不足によるクエリエラーの予兆を監視するには、AthenaのCloudWatch Eventsを参考にしてください。

最後に

Amazon Athena では、これまでスキャン量に応じた課金体系しかなく、使用料金の見積もりが難しくありました。また、大量のクエリを送信した際にキューイングが発生する可能性がありました。Provisioned Capacity を使用することにより、DPU と時間に応じた課金になるため料金の予測がしやすくなります。また、十分なコンピューティングリソースをプロビジョニングしておくことでレスポンスの改善が期待されます。使用料金の予測やキューイングによるレイテンシに課題のあったお客様にとって、Provisioned Capacity の提供は待望の機能でしょう。

お客様が、AWSクラウドでデータ分析をスモールスタートするのに、コスト効率の優れたクエリエンジンであるAmazon Athenaを採用した場合、データレイクが大きく育った段階で他AWSのアナリティクスサービスと組み合わせる場面がありましたが、今後はProvisioned Capacityを用いて解決するという選択肢が提供されました。

Provisioned Capacityは、RI（Reserved Instance）に例えるなら、8時間以上の前払いなしのRIを動的に購入して適用するのに近いのではないでしょうか。将来的にProvisioned CapacityにRI（Reserved Instance）、、、というかRC（Reserved Capacity）などのリリースが期待されます。

合わせて読みたい